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METHOD AND SYSTEM FOR DECODING CHARGING 
DATA RECORDS IN MOBILE TELEPHONE NETWORKS 

CROSS REFERENCE TO RELATED APPLICATIONS 
This application is the US national phase of PCT 
s application PCT/EP03/01978 , filed 26 February 2003, published 18 
September 2003 as WO 2003/077527, and claiming the priority of 
Italian patent application TO2002A000201 itself filed 8 March 
2002, whose entire disclosures are herewith incorporated by 
reference . 

10 FIELD OF THE INVENTION 

The present invention relates to the problem of 
decoding the so-called Charging Data Records (normally known by 
the acronym CDR) emitted by the nodes of a mobile telephone 
network . 

is BACKGROUND OF THE INVENTION 

Such charging data records are currently decoded by 
employing solutions based on software applications, which, for 
example, decode GSM network records separately from those of an 
associated GPRS network. Specifically, the application is 

20 developed manually starting from the record coding 

specifications, and each time there is a modification/new release 
of the GSM and/or GPRS systems and when new functions are added, 
parts of the software must be to some extent rewritten. 

There is consequently a need to provide solutions that 

25 can decode both GSM and GPRS format records, and for solutions 
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that take into account the frequent updating of the record format 
after the introduction of new GSM and GPRS network services /per- 
formances , as well as the possibility of easy extension of the 
application to new functions such as UMTS. 
5 SUMMARY OF THE INVENTION 

The solution, according to this invention, basically 
envisages the automatic generation of the logic that decodes the 
records . Whereas known solutions include the rewriting of the 
record decoding software whenever variations are introduced by 

10 the MSC manufacturer (Mobile Switching Center) or SGSN/GGSN 

(Serving GPRS Support Node and Gateway GPRS Support Node) , the 
solution according to the invention simply requires the 
manufacturer to provide a formal record description of the ASN.l 
type (Abstract Syntax Notation One) . 

15 The solution, according to the invention, then uses 

this description to directly generate the code that decodes the 
data record. As a result, the decoder adaptation times can be 
cut from several weeks to a few days, making it easy to keep 
right up to date with the mobile network's frequent alterations. 

20 The solution, according to the invention, includes the 

decoding of GSM records and GPRS records , which means that a 
single tool can be used on a mixed network employing both 
technologies . This is particularly advantageous if one considers 
that the operators of large-scale mobile telephone networks use 

25 both technologies in the network, in conditions in which the 
network update is carried out asynchronously. 
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The solution, according to the invention, proposes to 
decode the data records for GSM and GPRS functions , but its main 
features also make it easy and quick to extend the solution to 
other functions such as UMTS. 
5 BRIEF DESCRIPTION OF DRAWINGS 

The invention is hereafter described, by way of a non- 
limiting example only, with reference to the annexed drawings 
wherein : 

Figure 1 is a functional block diagram illustrating the 
10 general architecture and the input/output/control relationships 
of a system that operates according to the invention, and 

Figure 2 is a flow diagram illustrating the main stages 
into which the method is divided according to the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
15 As shown in Figure 1, the illustrated system, referred 

to with 10, has a main element, which is a processing core 12, 
destined to input a file 14 to be decoded, which then outputs a 
corresponding decoded file 16. The system 12 works on the basis 
of a decoding logic that is directly self- generated from the 
20 formal description ASN.l contained in a file 20 received from the 
outside. As already known, the description of the records in 
ASN.l (or equivalent, and consequently a description "of the 
ASN.l type") constitutes a set of specifications that describe 
the coding format of the records in ASN.l Notation or equivalent. 
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The input or log file 14 contains the records generated 
by the real network equipment (MSC for GSM records or SGSN/GGSN 
for GPRS records) in coded hexadecimal format. 

The decoding operation is run on the basis of the set 
s of user parameters that characterize the log file, the type of 
record (SGM/GPRS) and the output format. 

In particular, starting from an initial step 100, the 
first steps in the operating sequence of the system 10 include 
the reading of the parameters sent to output, which are: 
10 type of record to be decoded: GSM or GPRS (read by the 

system in step 102) , 
name of the log file to be decoded (step 104) , 
decoding format, i.e. the output format of the decoded 
file (read in step 106) ; this format may be 
15 "long", when the decoding, the length and the 

contents in hexadecimal are given for each record 
field, or "short", when only the decoding is given 
for each record field, 
log file containing the records to be decoded (step 
20 108) , and 

formal record description of the ASN.l type (step 110). 
Depending on the record description, an interpreter, 
such as an ASN.l interpreter, included in the processing core 12 
(see block 18 in Figure 1) creates and runs a series of 
25 procedures (collectively referred to as 112) , which in terms of a 
self-generation operation, create an updated version of the GSM 
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decoder (step 114) or GPRS decoder (step 116) according to the 
type of record read in step 102. 

The type of decoder selected (114 or 116) according to 
the parameter indicating the type of record (step 102) is further 
s parameterized according to the parameters read in steps 104 and 
106 (log file name and decoding format) . 

Once the decoder has been updated and programmed, it 
inputs (step 118) the file 14 containing the records to be 
decoded, and then outputs (step 120) the file containing the 
10 records decoded in text format. Reference 122 indicates the 
final step in the procedure. 

Naturally, numerous changes can be made to the 
construction and embodiments of the invention envisaged and 
illustrated herein, without however departing from the scope of 
15 the present invention. 
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